Date: Mon, 7 Oct 1996 12:11:36 -0700 From: Thomas Pfenning <thomaspf@microsoft.com> To: "'Denis DeLaRoca 825-4580'" <CSP1DWD@MVS.OAC.UCLA.EDU>, "'multimedia@FREEBSD.ORG'" <multimedia@FREEBSD.ORG> Subject: RE: Re: RealAudio on FreeBSD Message-ID: <c=US%a=_%p=msft%l=RED-81-MSG-961007191136Z-23669@mail3.microsoft.com>
next in thread | raw e-mail | index | archive | help
The queue length for vat is supposed to be self controlled. When my memory serves me right Van explained this to me in the following way. Vat uses the mike input to clock the output device meaning for every packet played out he is reading a packet from the mike. The queue length is automagically adjusted by preemption. The first time vat is preempted while received packets a number of packets will fill up in the receive buffer. These are then played out afterwards with the queue staying at that level. Next time vat is preempted you should have the right number of packets in the buffer. Over time you reach a level good enough for the longest preemption interval. Cheers Thomas >-----Original Message----- >From: Denis DeLaRoca 825-4580 [SMTP:CSP1DWD@MVS.OAC.UCLA.EDU] >Sent: Monday, October 07, 1996 8:22 AM >To: multimedia@FREEBSD.ORG >Subject: Re: Re: RealAudio on FreeBSD > >On Sun, 06 Oct 1996 14:50:10 -0700, > Amancio Hasty <hasty@RAH.STAR-GATE.COM> said: > >> Wait a little longer , I had a problem over here with my version of >> vat which was triggered by the sound driver. So far vat seems to work >> okay. For instance, I was listening to CBC news last night. The only >> gotcha is that sometimes vat gets behind and the sound gets distorted. >> It is a little difficult to fix because the sound buffering is setup >> for 20ms 8) > >The way I understand it, the 20ms is a compromise figure to minimize >system buffering to reduce latency vrs the need to have enough buffer >to maintain playout during processing and scheduling delays -- both >sender and receiver must agree on it as Vat uses audio read comple- >tions as a clock for issuing audio writes. Since audio packets from >the net may arrive late, and even out of order, Vat also keeps a playout >buffer whose playout-point is adjusted typically on a per talk-spur >basis -- this way net delays and even sender/receiver clock differences >can be smoothed. > >What does it mean when you say "vat gets behind and sound gets distor- >ted"? If Vat gets behind because of a processing/scheduling delay that >should show as a silence gap on the audio stream. If the receiver play- >out point increases linearly until it hits max, packets are dropped >resulting in sound clipping. I don't know if Vat currently tries to >handle this situation by estimating both the playout point and trend >in the estimate to implement selective packet discards in order to >achieve steady state -- though the resulting sound might not be perfect. > >I think the observed sound distortion here, gus sound driver, is due to >problems with the sound driver and little to do with the choice of 20ms >audio buffers. I don't see this behaviour in say a Sun workstation >where the same algorithms yield reasonably clear audio under similar >network conditions with also full-duplex audio hardware. > >Amancio, I am looking forward to the new sound driver. Right now, >besides the distorsion introduced by the sound hardware repeating >previous sound samples I have seen the following problems: > > a) sliders don't seem to work > b) the mike doesn't seem to work, the uv meter jumps off-scale > when opening the mike. > c) when activating two Vats, when teh 2nd copy tries to grab > the audio device I end up with a sleuth of error messages > > failed to set non-block mode for /dev/audio 9 > > d) when receiving audio with vat I keep seeing error mesages > > isa_dmastart: dma channel # busy > > >-- Denis >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c=US%a=_%p=msft%l=RED-81-MSG-961007191136Z-23669>